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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 of the LoCation Services (LCS) feature in GERAN, which provides the 
mechanisms to support mobile location services for operators, subscribers and third party service providers. 

The purpose of this stage 2 specification is to define the GERAN LCS architecture, functional entities and operations to 
support location methods. This description is confined to the aspects of LCS within the GERAN and does not define nor 
describe the LCS entities or operations within the Core Network. 

Location Services may be considered as a network provided enabling technology consisting of standardised service 
capabilities, which enable the provision of location applications. The application(s) maybe service provider specific. 
The description of the numerous and varied possible location applications which are enabled by this technology are 
outside the scope of the present document. However, clarifying examples of how the functionality being described may 
be used to provide specific location services may be included. 

This stage 2 specification covers the GERAN LCS functional model and entities, the location methods, state 
descriptions, and message flows. 
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Definitions and abbreviations 



3.1 Definitions 



For the purposes of the present document the following terms and definitions apply and the terms and definitions given 
in 3GPPTS 22.101 . 

LCS (Location Services): LCS is a service concept in system standardisation. LCS specifies all the necessary network 
elements and entities, their functionality, interfaces, as well as communication messages, due to implement the 
positioning functionality in a cellular network. Note that LCS does not specify any location based (value added) 
services except locating of emergency calls 

LCS Client: a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location 
information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information. 
LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting 
data and managing the user interface (dialogue). The LCS Client may reside in the Mobile Station (MS) 

LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services 
requests, and sends back responses to the received requests. The LCS server consists of LCS components, which are 
distributed to one or more PLMN and/or service provider 

Location Estimate: the geographic location of an MS and/or valid Mobile Equipment (ME), expressed in latitude and 
longitude data. The Location Estimate shall be represented in a well-defined universal format. Translation from this 
universal format to another geographic location system may be supported, although the details are considered outside 
the scope of the primitive services 

Mobile Assisted positioning: any mobile centric positioning method (e.g. E-OTD, GPS) in which the MS provides 
position measurements to the network for computation of a location estimate by the network. The network may provide 
assistance data to the MS to enable position measurements and/or improve measurement performance 

Mobile Based positioning: any mobile centric positioning method (e.g. E-OTD, GPS) in which the MS performs both 
position measurements and computation of a location estimate and where assistance data useful or essential to one or 
both of these functions is provided to the MS by the network. Position methods where an MS performs measurements 
and location computation without network assistance data are not considered within this category 

Mobile Station: the mobile station (MS) consists of Mobile or User Equipment (ME or MS) with a valid SIM or USIM 
attached. 
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Positioning (/location detecting): positioning is a functionality, which detects a geographical location (of e.g. a mobile 
terminal) 

Positioning technology (/locating technology): a technology or system concept including the specifications of RF 
interfaces, data types, etc. to process the estimation of a geographical location, e.g. GPS and E-OTD 

Radio Interface Timing: Comprise Absolute Time Differences (ATDs) or Real Time Differences (RTDs) of the 
signals transmitted by Base Stations, where timing differences are measured relative to either some absolute time 
difference (ATD) or the signals of another Base Station (RTD). 

RRLP pseudo-segmentation: The use of several RRLP data messages to deliver a large amount of assistance data 

Target MS: the Mobile Station being positioned 

Type A LMU: accessed exclusively over the air interface (Um interface): there is no wired connection to any other 
network element. 

Type B LMU: is accessed over the Abis interface from a BSC. The LMU may be either a standalone network element 
addressed using some pseudo-cell ID or connected to or integrated in a BTS. Note, Abis interface is beyond the scope 
of this document. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 21.905 apply. 

2G- Second Generation 

3G- Third Generation 

A Interface between GERAN BSS and MSC 

A-GPS Assisted GPS 

ATD Absolute Time Difference 

BSSLAP Base Station System Application Part 

BSSAP-LE Base Station System Application Part LCS Extension 

CBC-BSC Interface between CBC and BSC 

CBC-SMLC Interface between CBC and SMLC 

D-GPS Differential GPS 

E-OTD Enhanced Observed Time Difference 

Gb Interface between GERAN BSS and SGSN 

Lb Interface between SMLC and BSC 

LCCF Location Client Control Function 

LCF Location Client Function 

LSBcF Location System Broadcast Function 

LSCF Location System Control Function 

LSOF Location System Operation Function 

PCF Position Calculation Function 

PRCF Positioning Radio Co-ordination Function 

PRRM Positioning Radio Resource Management 

PSMF Positioning Signal Measurement Function 

RIT Radio Interface Timing 

RRLP Radio Resource Link Protocol 

RTD Real Time Difference 

SMSCB Short Message Service Cell Broadcast 

SMLCPP Serving Mobile Location Center Peer Protocol 

TA Timing Advance 

UDT SCCP Unitdata message 

Um GERAN Air Interface 

UTC Universal Coordinated Time 
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Main concepts 



A general description of location services and the service requirements is given in the specification 3GPP TS 22.071 0. 
By measuring radio signals the capability to determine the geographic location of the mobile station (MS) shall be 
provided. The location information may be requested by and reported to a client (application) associated with the MS, 
or by a client within or attached to the Core Network. The location information may also be utilised internally by 
GERAN, for example to support features such as home location billing. The location information shall be reported in 
standard formats, such as those for cell based or geographical coordinates of the location of the MS. 

It shall be possible for the majority of the MS (active or idle) within a network to use the feature without compromising 
the radio transmission or signalling capabilities of the GERAN. 

Three positioning mechanisms are supported for LCS: Timing Advance (TA), Enhanced Observed Time Difference (E- 
OTD), and Global Positioning System (GPS). 

4.1 Assumptions 

SMLC is either an integrated functionality in BSC or a standalone network element within GERAN. 

LMU is either an integrated functionality in BTS (Type B LMU) or a standalone network element (Type A 
LMU) where communication is over the Um interface. 

Positioning not supported on Gb interface, but paging GPRS mobiles supported for Circuit Switched mode 
positioning. 

4.2 Standard LCS IVIethods 

4.2.1 Timing Advance 

The TA is based on the existing Timing Advance (TA) parameter. The TA value is known for the serving BTS. To 
obtain TA values in case the MS is in idle mode a special procedure, not noticed by the GSM subscriber (no ringing 
tone), is set up. The cell-ID of the serving cell and the TA is returned as the result of the TA. 

TA may be used to assist all positioning mechanisms and is a fall-back procedure. 

4.2.2 Eninanced Observed Time Difference (E-OTD) positioning 
mecinanism 

The E-OTD method is based on measurements in the MS of the Enhanced Observed Time Difference of arrival of 
bursts of nearby pairs of BTSs. For E-OTD measurement synchronization, normal and dummy bursts are used. When 
the transmission frames of BTSs are not synchronized, the network needs to measure the Real or Absolute Time 
Differences (RTDs or ATDs) between them. To obtain accurate trilateration, E-OTD measurements and, for non- 
synchronized BTSs, RTD or ATD measurements are needed for at least three distinct pairs of geographically dispersed 
BTSs. Based on the measured E-OTD values the location of MS can be calculated either in the network or in the MS 
itself, if all the needed information is available in MS. 

4.2.3 Global Positioning System (GPS) positioning mechanism 

The Global Positioning System (GPS) method refers to any of several variants that make use of GPS signals or 
additional signals derived from GPS signals in order to calculate MS position. These variants give rise to a range of 
optional information flows between the MS and the network. One dimension of variation is where position calculation 
is performed at: a) MS-based PCF or b) network-based PCF. Another dimension is whether "assistance data" is 
required - irrespective of where position calculation is performed. Examples of assistance data include differential GPS 
data; lists of satellites in view based on approximate MS position, etc. A third dimension of variation is closely related 
to the preceding, namely, the origin and distribution of any assistance data. For example, even while assistance data 
may be required of a GPS method, it may be optional that the assistance data originates from and is distributed within 
and by the PLMN, VPLMN, etc. 



£75/ 



3GPP TS 43.059 version 4.2.0 Release 4 



11 



ETSI TS 143 059 V4.2.0 (2001-08) 



GERAN LCS Architecture 



Figure 1, shows the general arrangement of the Location Service feature. This illustrates, generally, the relation of LCS 
Clients and servers in the core network with the GERAN. The definition and operation of LCS entities operating in the 
core network is outside the scope of the present document. The LCS entities within the GERAN communicate with the 
Core Network (CN) across the A and Gb interfaces. 

Communication among the GERAN LCS entities makes use of the messaging and signalling capabilities of the 
GERAN. 

As part of their service or operation, the LCS Clients may request the location information of Mobile Station. There 
may be more than one LCS client. These may be associated with the core network, associated with the GERAN, 
operated as part of a MS application or accessed by the MS through its access to an application (e.g. through the 
Internet). 

Within the GERAN, the BSC receives authenticated requests for LCS information from the core network across the A 
and Gb interfaces and passes these to the SMLC. The SMLC may be a standalone network element or functionality that 
is integrated to the BSC. LCS entities then manage the GERAN resources, including the base station, the LMU, the MS 
and calculation functions, to estimate the location of the MS and return the result to the Core Network. 



MS 



Urn 







BSS 



GERAN 



Lb 



SMLC 



CBC-BSC 



CBC 



CBC-SMLC 



Gb 



GSM/UMTS 
Core Network 



Figure 1 : Functional LCS Architecture in GERAN 

Note: Positioning not supported on Gb interface, but paging GPRS mobile supported for Circuit Switched mode 
positioning. 



5.1 LCS Operations 



The schematic functional description of LCS operations is defined in Figure 2. 

Upon request from the LCS entities or for internal operations, the GERAN LCS functional entities will: 

request measurements, typically from the MS and/or one or more BTS radio apparatus; 

send the measurement results to the appropriate calculating function within GERAN; 

receive the result from the calculating function within GERAN; 

send the results to the LCS entities in the core network or to application entities within GERAN. 
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In the event that the cHent is internal to GERAN the request may be made directly to the GERAN LCS entities as the 
internal clients are considered to be "pre-authorised". 

As part of its operation, the GERAN LCS calculating function may require additional information. This may be 
obtained by the function directly by communication with a database, or it may be through a request to GERAN LCS 
entities that will mediate the request and return of information from the appropriate database (or databases if more than 
one is needed to fulfil the requests). 

There may possibly also be available independent information that is able to supply the location information directly, or 
may be able to supply auxiliary information to the calculation function. The GERAN LCS co-ordination function, as 
part of its activity to supervise the location process, may query the MS or other elements of the GERAN to determine 
their capabilities and use this information to select the mode of operation. 

This general operation is outlined in the following (generic) sequence diagram Figure 2. This figure is not intended to 
show the complete LCS operation for GERAN, but to simply to outline the basis for operation. Location measurements 
may continually be taken in the background. 



CNLCS 
Entities 



GERAN Coordination l\/leasurement Calculation 
Entities 



Location 



Request 



measure request 



measurements 



calculation request 



calculation results 



Location 



Response 



Figure 2: General sequence for LCS operation 



5.2 High-Level Functions 



Several functional groupings may be defined to describe the LCS. These groupings occur in both the Core Network and 
the GERAN. The overall LCS functional grouping is described in the system stage 2, 3GPP TS 23.271 0. Each grouping 
encompasses a number of functional components and functions. 

The functions within the GERAN are described in more detail in the following subclauses of the present document. 

Within GERAN the functional entities may be grouped as follows: 

the Internal Client group; 

the GERAN System Handling group; 

the Positioning group. 

The LCS functional diagram shown in Figure 3 depicts the interaction of the LCS functional entities within the 
GERAN. The GERAN uses the various LCS components to provide the target MS Location Information to the internal 
LCS client. 
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Internal Client 

LCF 



Location 
Request 



Location 
Response 



GERAN System Handling 

LSCF 
LSOF 
LSBcF 



PCF 



Positioning Group 

PRCF 



PSMF PRRM 



Figure 3: GERAN LCS Capability Functional Diagram 

5.2.1 Co-ordination, Measurement and Calculation Functions 

These GERAN functions (including functions in the System handhng and Positioning groups) provide the 
co-ordination, measurement and calculation functions needed to provide a location estimate. The functions interface 
with the requesting application and select the appropriate location method and speed of response. The functions 
co-ordinate the operations of the radio and measurement equipment to transmit the needed signals and to make the 
needed measurements. The functions may also access databases or other sources of information appropriate for the 
location method. The functions also provide the calculation functions appropriate for the location method to estimate 
the MS location and the accuracy of the report. The functions also may record information on the usage of the LCS that 
may be used for administrative purposes (e.g. forwarded to a billing function in the Core Network). If needed by the 
location method, the functions will ensure the broadcast of information and gather and update information concerning 
GERAN operating parameters (e.g. timing of BTS transmissions) needed for LCS operations. 

These entities are mainly concerned with the location method, controlling the radio equipment and performing the 
calculations to determine the location and thus may be associated with the SMLC in the GERAN. These functions may 
receive location requests from either the core network or from applications internal to the GERAN. 

These functions communicate with the core network across the A and Gb interfaces, and with the BTS and LMU and 
with the MS across the Um interface. 
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5.3 GERAN LCS Functional Entities 

5.3.1 Internal Client Group 

5.3.1 .1 Internal GERAN Location Client Function (LCF) 

The Location Client Function (LCF) represents a logical interface between the internal GERAN LCS applications and 
the LCS BSC Handling entities (e.g. the Location System Control Function (LSCF) in the BSC). 

NOTE: There is not necessarily a requirement for a LCCF (Location Client Control Function) for the GERAN 
Internal Client as is described for external clients in the system stage 2 specification, 3GPP TS 23.271 0. 

The GERAN may make use of location information for internal operations such as location assisted handover. In such a 
case, a LCF representing the internal GERAN LCS application may communicate with the LSCF to request and receive 
the location information. 

5.3.2 GERAN System Handling group 

5.3.2.1 GERAN Location System Control Function (LSCF) 

The GERAN Location System Control Function is responsible for co-ordinating location requests. This function 
manages call-related and non-call-related location requests and allocates network resources for handling them. This 
function "insulates" the Location clients in the Core Network from the detailed operation of the location method in 
order that the GERAN may be used by several types of core network and with several location methods. 

The LSCF provides flow control between simultaneous location requests. Simultaneous location requests must be 
queued in a controlled manner to account for priority requests (e.g. for Emergency Clients). The details of the flow 
control, priority selection and queuing are beyond the scope of the present document. 

The LSCF will select the appropriate location method based on the availability of resources and parameters of the 
location request. The LSCF coordinates resources and activities needed to obtain data (e.g. base station geographic 
coordinates) needed for the location method. It also records LCS usage data for the location service request that may be 
passed to a Location System Recording Function (LSRF) or O&M function in the Core Network. 

5.3.2.2 GERAN Location System Operations Function (LSOF) 

The Location System Operations Function (LSOF) is responsible for provisioning of data, location capabilities, data 
related to clients and subscription (LCS client data and MS data), fault management and performance management of 
LCS within the BSC. 

An LSOF may be associated with each entity. The LSOF interacts with Internal (O&M) Clients for administration and 
maintenance of the data. 

5.3.2.3 Location System Broadcast Function (LSBcF) 

The Location System Broadcast Function (LSBcF) provides broadcast capability. The LSBcF capability is only used 
when broadcast data is required for E-OTD or A-GPS positioning methods. Broadcast information (such as the 
geographic coordinates of the base stations) may be required, for example, to support a Position Calculation Function 
(PCF) located in the mobile station. These broadcasts may also include other information (such as currently observable 
satellites) that may assist a MS in the use of external location services. 

The information to be broadcast is selected based on the location techniques offered for use by the LCS and the needs of 
the MS. This broadcast information may be specially coded (i.e. encrypted) to ensure its availability only to subscribers 
of the service. The use of broadcasts or other methods for signalling to the MS may be selected based on the chosen 
location method. 
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The information to be broadcast includes for example: 

1, E-OTD Assistance: 

Reference Time 

Neighbour Channel Time Slot Scheme 
Information about sectored neighbour channels 
Neighbour channel 5 1 Multiframe Offset values 
Neighbour channel BCC values 
RTD Drift Factor values (ciphered if active) 
Neighbour channel RTD values (ciphered if active) 
Serving cell and neighbour cell location information (ciphered if active) 

2. GPS Assistance Data: 

Reference Time 
Reference Location 
- Differential GPS Correction Data (DGPS) 
Ephemeris and Clock Correction Data 
Almanac and Other Data. 

5.3.3 Positioning group 

5.3.3.1 GERAN Position Radio Co-ordination Function (PRCF) 

The GERAN Position Radio Control Function manages a location request for a MS through overall co-ordination and 
scheduling of resources to perform location measurements. This function interfaces with the PSMF, the PRRM and the 
PCF. The PRCF determines the location method to be used based on the location request, the QoS, the capabilities of 
the GERAN, and the MS's capabilities. The PRCF also manages the needed radio resources through the PRRM. It 
determines which PSMFs are to be involved, what to measure, and obtains processed signal measurements from the 
PSMF. 

Some location methods may involve measurements made at the MS. In this case the PRCF interfaces with the MS to 
obtain the measurements (or the location results if they have been determined by the MS). Some location methods may 
involve measurements or information from several sources, including radio units at several BTSs and involve a series of 
transmissions and receptions. The PRCF entity also provides ancillary measurements in case of network-assisted 
location method. Ancillary information may be extracted from navigating systems like GPS. 

The PRCF forwards the signal measurement data to the PCF. 

It is the function of the PRCF to co-ordinate the sequence of activities and compensate for failures (if they occur) to 
provide the location estimate. 

5.3.3.2 GERAN Position Calculation Function (PCF) 

The GERAN Position Calculation Function is responsible for calculating the location of the MS. This function applies 
an algorithmic computation on the collected signal measurements to compute the final location estimate and accuracy. 

It may obtain related data (e.g.: base station geographic coordinates) needed for the calculation. There may be more 
than one calculating function available within, or associated with, the calculation function of the GERAN. 

The Position Calculation Function is also responsible for estimating the accuracy of the location estimate. 
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5.3.3.3 GERAN Position Signal IVIeasurement Function (PSIVIF) 

The GERAN Position Signal Measurement Function (PSMF) is responsible for performing and gathering uplink or 
downlink radio signal measurements for use in the calculation of a MS's location. These measurements can be location 
related or ancillary. 

There may be one or more PSMF within a GERAN and they may be located at the MS or a Location Measurement Unit 
(LMU). The PSMF, generally, may provide measurement of signals (i.e. satellite signals) in addition to measurements 
of the GERAN radio transmissions. The measurements to be made will depend on the selected location method. 

5.3.3.4 GERAN Position Radio Resource IVIanagement (PRRIVI) 

The GERAN Position Radio Resource Management entity is responsible for managing the effect of LCS operations on 
the overall performance of the radio network. This may ensure, for example, that the operation of the PSMF does not 
degrade the QoS of other calls. 
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5.4 Assignment of LCS Functional Entities to GERAN Elements 

The following Table 1 shows the generic configuration for different location methods, including network-based, 
mobile-based, mobile-assisted and network-assisted methods. With this approach both the network and the mobiles are 
able to measure the timing of signals and compute the mobile's location estimate. Depending on the applied location 
method it is possible to utilise the corresponding configuration containing all needed entities. For instance, if a network- 
based location method is applied, the entities that are involved in measuring the mobile's signal and calculating its 
location estimate are allocated to the network elements of the access network. On the other hand, in case mobile-based 
or network-assisted methods are used these entities should be allocated to the mobile station. 

Table 1: Example Allocation of LCS Functional Entities to Network Elements 
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5.5 Functional Description of GERAN LCS Network Elements 



5.5.1 



BSC 



The BSC receives authenticated requests for LCS information from the CN across A and Gb interfaces and passes these 
to the SMLC. 

5.5.2 SMLC 

The SMLC is either a separate network element of GERAN or integrated functionality in BSC that contains 
functionality required to support LCS. The SMLC manages the overall co-ordination and scheduling of resources 
required for the location of a mobile. It also calculates the final location estimate and estimates the achieved accuracy. 
The SMLC may control a number of LMUs for the purpose of obtaining radio interface measurements to locate or help 
locate MS subscribers in the area that it serves. The SMLC is administered with the capabilities and types of 
measurement produced by each of its LMUs. The radio interface timing measurement returned by an LMU to a SMLC 
has a generic status in usable for more than one location method. 

5.5.3 CBC 

For Location Services, when a Cell Broadcast Center (CBC) is associated with a BSC, the SMLC may interface to a 
CBC in order to broadcast assistance data using existing cell broadcast capabilities. The SMLC shall behave as a user. 
Cell Broadcast Entity, to the CBC (refer to 3GPP TS 23.041 0). 



5.5.4 



LMU 



The LCS Measurement Unit (LMU) entity makes measurements (e.g. of radio signals) and communicates these 
measurements to the SMLC (e.g. the PRCF). The LMU contains a PSMF and may also perform calculations associated 
with the measurements. The LMU may make its measurements in response to requests (e.g. from the SMLC), or it may 
autonomously measure and report regularly (e.g. timing of BTS transmissions) or when there are significant changes in 
radio conditions (e.g. changes in the RTD). There may be one or more LMUs associated with the SMLC and an LCS 
request may involve measurements by one or more LMUs. LMU functionality may be integrated in a BTS. 
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An LMU makes radio measurements to support one or more positioning methods; these assistance measurements are 
specific to all MSs in a certain geographic area. All location and assistance measurements obtained by an LMU are 
supplied to the SMLC associated with the LMU. Instructions concerning the timing, the nature, and any periodicity of 
these measurements are either provided by the SMLC or are pre-administered in the LMU. 

The following assistance measurement obtained by an LMU has a generic status usable by more than one position 
method: 

Radio Interface Timing measurements - comprise Absolute Time Differences (ATDs) or Real Time 
Differences (RTDs) of the signals transmitted by Base Stations, where timing differences are measured relative 
to either some absolute time difference (ATD) or the signals of another Base Station (RTD). 



5.5.5 



MS 



The MS interacts with the measurement co-ordination functions to make measurements of downlink signals. The 
measurements to be made will be determined by the chosen location method. 

The MS may also contain LCS applications, or access an LCS application through communication with a network 
accessed by the MS or an application residing in the MS and/or satellite signals. The MS may include the needed 
measurement and calculation functions to determine the MS's location with or without assistance of the GERAN LCS 
entities. 



6 Signalling Protocols and Interfaces 

6.1 Protocol layering in CS domain 

6.1 .1 Generic Signalling Model for LCS in CS Domain 

Figure 4 shows the generic signalling model applicable to LCS for signalling interaction in which an SMLC forms at 
least one of the signalling end points in the circuit switched domain. 
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Figure 4: Generic Model for LCS Signalling to an SMLC for CS domain 

The functions performed by each protocol layer are as follows: 

a) LCS application protocol - this depends on the other signaling end point (e.g. whether a target MS or LMU) and 
may be absent if supported in the BSSAP-LE layer. The application protocol supports specific LCS functions 
(e.g. positioning measurements, assistance measurements) and is independent of lower protocol layers. 
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b) BSSAP-LE - this is an extension of BSSAP and carries the LCS application protocol signaling units. Necessary 
functions include identification of the LCS application protocol and identification, where not provided by the 
network layer, of the two end points. This layer can be relayed by an intermediate entity or mapped into an 
equivalent layer 3 protocol used by the other signaling end point. This layer supports segmentation of LCS 
application layer protocols. 

c) Network Layer - provides signaling transport between the SMLC and either the other end point or some 
intermediate entity at which the BSSAP-LE layer is relayed or mapped. The network layer may support 
connection oriented or connectionless signaling. For second generation circuit oriented applications, the network 
layer is provided using MTP and SCCP. This layer supports segmentation of LCS application layer protocols. 

d) Physical Layer - for second generation circuit oriented applications, SS7 signaling links are supported by the 
physical layer. 

e) L3 - a protocol layer compatible with or the same as BSSAP-LE. 

f) L2 - logical link layer for the other endpoint 

g) LI - physical layer for the other end point. 

6.1 .2 Message Segmentation in CS Domain 

Message segmentation is needed to transport any large LCS message that exceeds the message size limitation supported 
by any GSM interface over which transport is needed. 

6.1 .2.1 Network Level Segmentation 

Segmentation and reassembly of large RRLP, SMLCPP and BSSLAP messages at the network (e.g. SCCP) level may 
be supported. For message transfer over any interface where network level segmentation is not supported, segmentation 
at the application level shall be used. This may require support of both network and intermediate level segmentation by 
certain intermediate entities.Intermediate Level Segmentation 

6.1 .2.2 Intermediate Level Segmentation 

The segmentation of RRLP 3GPP TS 44.0310, SMLCPP 3GPP TS 48.0310, and BSSLAP 3GPP TS 48.071 messages 
is supported by segmentation mechanisms defined in 3GPP TS 48.008 , 3GPP TS 24.008 0, 3GPP TS 44.018 and 
3GPP TS 49.031 0. The sending, receiving and all intermediate entities supporting segmentation shall ensure reliable 
and sequenced delivery of the message segments by appropriate use of the capabilities supported by lower transport and 
network level protocols 

6.1.2.3 RRLP Pseudo-Segementation 

The use of several RRLP messages to deliver a large amount of assistance data is called "RRLP pseudo-segmentation". 
In order to avoid excessive delays for MM and CM layer procedures (call setup for example) it is recommended to 
utilize the "RRLP pseudo-segmentation " and limit the maximum size of individual RRLP messages (e.g. 
approximately 240 octets will avoid lower layer segmentation). 



£75/ 



3GPP TS 43.059 version 4.2.0 Release 4 



20 



ETSI TS 143 059 V4.2.0 (2001-08) 



6.1 .3 Signalling between an SMLC, MSC and BSC 

A SMLC can either be separate logical entiy or integrated functionality in the BSC. If the SMLC is a separate logical 
entiy, the LCS signalling between SMLC and MSC is accomplished through the A and Lb interfaces. If the SMLC is 
integrated, the LCS signalling is accomplished through the A interface only. Figure 5 shows the protocol layers used to 
support LCS signaling between the SMLC, MSC and BSC. 
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Figure 5: Signalling Protocols between SMLC, MSC and BSC 



6.1 .4 Signaling between SMLC and MS 



SMLC Signalling to a target MS is accomplised through the Um interface. The figure below shows the protocol layers 
used to support signaling between an SMLC and target MS. 
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Figure 6: Signalling between an SMLC and Target MS 
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6.1.5 SMLC Signalling to a Type A LMU 



6.1.5.1 



Circuit Switched Signalling using an SDCCH 



Figure 7 shows the protocol layers used to support signaling between an SMLC and a Type A LMU, using an SDCCH 
on the Um interface. 



LLP 
(44.071) 



DTAP 



RR 
(44.018) 



L2 
(LAPDm) 



LI 



LMU 



RR 


BSSAP-LE 


L2 

(LAPDm) 


SCCP 


LI 


MTP 



BSC 



LLP 
(44.071) 



BSSAP-LE 
(49.031) 



SCCP 



MTP 



Um Lb 

Figure 7: Signalling between an SMLC and Type A LMU using an SDCCH 
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6.1.5.2 



Signalling using a TCH 



Figure 8 shows the protocol layers that can be used to support signaling between an SMLC and a Type A LMU using a 
TCH on the Um interface. The TCH is assumed to support either transparent or non-transparent synchronous data and 
may be provided in a multislot configuration. The main usage would be for O&M data and SW download - e.g. during 
offpeak hours. 
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Figure 8: Signalling between an SMLC and a Type A LMU using a TCH 



£75/ 



3GPP TS 43.059 version 4.2.0 Release 4 



22 



ETSI TS 143 059 V4.2.0 (2001-08) 



6.1.6 SMLC signaling to a Type B LMU 



The protocol layers employed to enable signaling between the SMLC and a Type B LMU are shown in Figure 9. (Note 
1)*: Abis interface is beyond the scope of this document. 
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6.1.7 SMLC Signalling to a peer SMLC 



The protocol layers used for SMLC to SMLC signaling are shown in Figure 10, where it is assumed that both SMLCs 
have SS7 link connections to STPs (or there is a direct SS7 link between the SMLCs). 
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Figure 10: SMLC to SMLC Signalling via SS7 STPs 



In the absence of either a direct link or links to an STP, signaling can go via attached BSCs and MSCs as shown in 
Figure 1 1 for signaling between the SMLCs sharing the same MSC. 
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Figure 1 1 : SMLC to SMLC Signalling via associated BSCs and MSC 
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7 GERAN Network Location Procedures 

7.1 State description for SIVILC 
7.1.1 SMLC States 



7.1.1.1 



NULL State 



This is a conceptual rather than actual state in which a certain location request from a particular Location Client, 
VMSC, SGSN or BSC either has not yet been received or has been completed. 

7.1.1.2 LOCATION State 

This state exists after the SMLC has received a location request from a BSC and persists while the SMLC is obtaining 
position measurements for a particular positioning method until such time as positioning measurements have been 
received and a location estimate has been computed and returned to the BSC. 

When sufficient positioning measurement results have been received, the SMLC either evaluates them, if they include 
an already computed location estimate, or uses them to compute a location estimate. The SMLC then has the option of 
either reinitiating another positioning attempt, if the location estimate did not satisfy the required QoS, or returning the 
location estimate to the BSC. 
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7.1.2 State Functionality 
7.1.2.1 State Transitions 
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Figure 12: State Transitions in the SIUILC 

Moving from NULL to LOCATION state: 

After a location request is received from the BSC, the SMLC chooses a positioning method and initiates the appropriate 
position measurements. It then enters the LOCATION state. 

Moving from LOCATION to NULL state: 

When the SMLC has obtained a location estimate that best meets the requested QoS parameters, it returns this to the 
BSC and re-enters the NULL state. 

7.1 .2.2 LOCATION Timer Function 

The SMLC runs a timer while in the LOCATION state to limit the total amount of time that positioning can be active. 
This timer should be related to any response time indicated in the location request QoS parameters. If the timer expires 
before a final location estimate has been produced, the SMLC either returns the best existing location estimate to the 
BSC (e.g. an estimate based on the current cell ID) or returns a failure indication. It then re-enters the NULL state. 
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7.2 State Description for the BSC 
7.2.1 BSC States 
7.2.1.1 IDLE state 

In this state, the BSC location service is inactive for a particular MS. 



7.2.1.2 



LOCATION State 



In this state, the BSC is awaiting a response from a SMLC after requesting the location frjr a particular MS. In this 
state, a Radio Resource connection to the target MS will be active - allowing the SMLC and MS to exchange 
positioning related messages for mobile based and mobile assisted position methods. For certain position methods (e.g. 
network based position methods), the SMLC may invoke substates in the BSC during which other types of association 
or procedure are supported with the MS (e.g. temporary call establishment, handover). In this state, the BSC may 
transfer positioning related messages between the SMLC and the target MS and/or between the SMLC and certain 
LMUs served by the BSC. 

7.2.2 State Functionality 
7.2.2.1 State Transitions 



Request Location 
from SMLC 




Receive Location 
results from the SMLC 
or Timeout 



Transfer Positioning 
Messages 

Figure 13: State Transitions in the BSC 

Moving from IDLE to LOCATION state: 

After a request has been received to locate a particular MS served by the BSC, a location request is sent to the SMLC 
associated with the serving cell: the BSC then enters the LOCATION state. Before entering this state, a Radio Resource 
connection to the MS must have been already established by the VMSC. 

Moving from LOCATION to IDLE state: 

After the return of a location estimate result from the SMLC, the BSC shall re-enter IDLE state. 
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7.2.2.2 



LOCATION Timer Function 



The BSC runs a timer while in the LOCATION state to limit the amount of time waiting for a location response from 
the SMLC. If the timer expires before such information is received, the BSC indicates a location failure to the original 
requesting entity and re-enters IDLE state. 

7.3 Usage of SCCP Connection on the Lb interface 

SCCP connection oriented signaling between a SMLC and a BSC is used to support SMLC signaling to a Type A 
LMU, a serving BSC, or a target MS. The types of SCCP connections are described below. 

7.3.1 SCCP Connection for positioning of a target MS 

The BSC establishes this connection when a request is received for a location estimate for a target MS. The BSC sends 
the BSSAP-LE Perform Location Request to the SMLC inside an SCCP Connection Request message. Signaling 
between the SMLC and target MS is then relayed by the BSC between this SCCP connection and the main signaling 
link to the MS. The same SCCP connection is also used to transfer BSSLAP messages between the SMLC and serving 
BSC. See figure below. 
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Figure 14: SCCP based signalling for MS positioning with a SMLC 

7.3.2 SCCP connection to access a Type A LMU 

The BSC or SMLC establishes this connection to enable LCS messages to be transferred to or from a Type A LMU. 
The BSC or SMLC sends a BSSAP-LE LMU Connection Request message inside an SCCP Connection Request 
message. Signaling is subsequently relayed through the BSC using this SCCP connection as shown in the figure below. 




SDDCH or 
FACCH 




t 



SCCP 
Connection 



BSSAP-LE (49.031) 




LLP (44.071) 
Figure 15: SCCP based signalling to access a TypeA LMU with a SMLC 
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8 Common Procedures to Support Positioning 

The procedures described in this section enable an SMLC to obtain positioning related information or instigate 
positioning for a particular target MS. The procedures are applicable to all positioning methods after an SMLC receives 
a BSSAP-LE Perform Location request for a target MS until a BSSAP-LE Perform Location response is returned to the 
originator. 

8.1 Information Transfer between a SIVILC and a Target MS 

A SMLC uses the procedure shown below in order to obtain positioning measurements from a target MS or transfer 
location assistance information to a target MS after a request has been received from the BSC serving the target MS. 
More details of the location information transfer procedure between the BSC and MS can be found in 3GPP TS 24.008. 
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Figure 16: Information Transfer between a SMLC and a Target MS 

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the serving BSC containing an 
embedded BSSLAP MS Position Command with an RRLP message parameter. The message is transferred using 
the SCCP connection established between the SMLC and BSC for positioning the target MS If the BSSLAP 
message is too large to fit in a single BSSAP-LE Connection Oriented Information message, it may be 
segmented and transferred inside a sequence of BSSAP-LE messages with the last BSSAP-LE message 
containing a last segment indication and the last RRLP segment. The SMLC shall indicate in the first BSSLAP 
MS Position Command whether the embedded RRLP message contains a positioning command versus 
positioning assistance data. 

2) The BSC transfers the embedded RRLP message to the target MS inside an RR Application Information 
message. If the BSSLAP message was segmented by the SMLC, onward transfer to the MS shall be deferred 
until all segments have arrived and the complete BSSLAP message is reassembled. The embedded RRLP 
message shall then be re-segmented if necessary with each RRLP segment transferred in a separate RR 
Application Information message with the last RR message indicating the last RRLP segment. No later than 
when the last RR Application Information message has been transferred, the BSC shall start a positioning 
supervision timer if none is already in progress or restart this if already in progress. If the timer expires before 
the final response in step 3 is received, the BSC shall return a BSSAP-LE Connection oriented Information 
message to the SMLC containing a BSSLAP Abort with a cause of BSC timeout. 

3) When the target MS has positioning information to return to the SMLC, it sends an RR Application Information 
message to the BSC containing an embedded RRLP message. If the RRLP message is too large to fit in a single 
RR Application Information message, it may be segmented and carried in a sequence of RR Application 
Information messages with the last message indicating the last RRLP segment. The last RR Application 
Information message shall indicate if this is the final response from the MS. 
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4) If the timer started in step 2 has already expired, the BSC discards the RRLP message received in step 3. 
Otherwise, the BSC forwards the RRLP message to the SMLC inside a BSSLAP MS Positioning Response 
message contained in a BSSAP-LE Connection Oriented Information message. If the RRLP message was 
segmented, onward transfer to the SMLC shall be deferred until all segments have arrived and the complete 
RRLP message is reassembled. If the resulting BSSLAP message is too large to fit into a single BSSAP-LE 
Connection Oriented Information message (e.g. if the RRLP message was segmented), it shall be segmented. 
Each segment is then transferred in a separate BSSAP-LE message with the last message containing the last 
BSSLAP segment. If the SMLC indicated a positioning command in step 1 and the MS has indicated a final 
response, the BSC may add additional measurement information to the BSSLAP MS Position Response in the 
last BSSAP-LE message - if necessary, creating a new BSSAP-LE message if message size limitations would be 
exceeded. The BSC shall stop the supervision timer started in step 2 when the final segment of the final response 
from the MS has been transferred. If the MS did not indicate a final response in step 2, the SMLC may transfer a 
further RRLP message to the MS (e.g. containing assistance data) according to steps 1 and 2 and the MS may 
return a subsequent response according to steps 3 and 4. 



8.2 



Information Transfer between a SMLC and a BSC 



A SMLC uses the procedure shown below in order to obtain positioning related information from the BSC serving a 
particular target MS after a positioning request has been received from the BSC. 



SMLC 



BSC 



1 . SCCP DT1 [BSSMAP-LE Connectic 
Oriented Information] 



2 SCCP DT1 [BSSIVIAP-LE Connectic 
Oriented information] 



Figure 17: Information Transfer between a SMLC and a BSC 

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the BSC containing an embedded 
BSSLAP message. The BSSAP-LE message is transferred using the SCCP connection previously established 
between the SMLC and BSC when the positioning request for the target MS was initially sent to the SMLC. The 
BSC recognizes that it is the final destination due to the presence of the embedded BSSLAP message. 

2) When the BSC has positioning information for the target MS to return to the SMLC, it sends a BSSAP-LE 
Connection Oriented Information message to the SMLC containing an embedded BSSLAP message. The 
message is sent using the SCCP connection previously established for positioning the target MS. 

8.3 Common Procedures to Support Access to an LMU 

The procedures in this section support the transfer of positioning related information and O&M data between an SMLC 
and a particular LMU associated with the SMLC. 
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8.3.1 Location Update Procedure between a SMLC and a Type A LMU 

The following procedure supports a normal location update from the perspective of a Type A LMU. The location update 
can occur periodically, on power up, following recovery from some failure condition and when an LMU in idle mode 
detects that its closest BTS is in another location area. 



SMLC 



BSC 



2. SCCPCR[BSSMAP Corr plete Layer 3 
Information [Location Updating Request]] 



3. Normal GSM Autt 



4. DTAP Location Updating 



LMU 



1 . DTAP Location Updatinc 



entication, Ciphering 
Accept 



5. DTAP Location Updatin j Accept 



Request 



Figure 18: Location Update Procedure between a SIVILC and a Type A LIVIU 

1) If the LMU does not currently have a signaling link, it sends an RR Channel Request to the serving BTS to 
request a SDCCH. The RR Channel Request contains an establishment cause identifying an LMU. After 
assignment of the SDCCH, the LMU sends a DTAP Location Updating request to the BSC. This shall indicate 
that a follow on request is pending if the LMU has more data to send. 

2) Because the BSC serving the LMU is associated with a SMLC and the Channel Request message contained an 
LMU establishment cause, the BSC forwards the Location Updating request to the SMLC rather than MSC. If 
there was previously no SDCCH, this is sent inside a BSSMAP Complete Layer 3 Information message that is 
contained in an SCCP Connection Request. 

3) The SMLC performs normal authentication and ciphering if needed for the LMU. The SMLC shall not assign a 
TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS by a VLR. 

4) The SMLC returns a DTAP Location Updating Accept to the BSC. Unless the LMU indicated a follow on 
request, the SMLC may then initiate release of the SDCCH. 

5) The BSC forwards the DTAP message to the LMU. 

8.3.2 IMSI Detach Procedure between a SMLC and a Type A LMU 

The following procedure supports a normal IMSI Detach from the perspective of a Type A LMU. This may be 
instigated if the LMU is to be deactivated - e.g. for offline maintenance. 



SMLC 



BSC 



2. SCCPCR[BSSMAP Cor iplete Layer 3 
Information [IMSI Detact Indication]] 



LMU 



1 . DTAP IMSI Detach Indie ation 



Figure 19: IIVISI Detach Procedure between a SIVILC and a TypeA LMU 

1) If the LMU does not currently have a signaling link, it sends an RR Channel Request to the serving BTS to 
request a SDCCH. The RR Channel Request contains an establishment cause identifying an LMU. After 
assignment of the SDCCH, the LMU sends a DTAP IMSI Detach Indication to the BSC. 
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2) Because the BSC serving the LMU is associated with a SMLC and the Channel Request message contained an 
LMU establishment cause, the BSC forwards the IMSI Detach Indication to the SMLC rather than MSC. If there 
was previously no SDCCH, this is sent inside a BSSAP Complete Layer 3 Information message that is contained 
in an SCCP Connection Request. The SMLC marks the LMU as temporarily inactive and initiates release of the 
SDCCH. 

8.3.3 LCS Information Transfer between a SMLC and a Type A LMU 
8.3.3.1 Information Transfer using an SDCCH 

The following procedure supports information transfer between a SMLC and a Type A LMU. 
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Figure 20: Information Transfer between a SIVILC and a Type A LMU 

1) If there is no signaling Unk yet for an LMU between the SMLC and the BSC serving the LMU, the SMLC sends 
a BSSAP Paging message to the serving BSC inside an SCCP Unitdata message. 

2) The serving BSC broadcasts an RR Paging Request. 

3) The LMU sends a Channel Request message containing an LMU establishment cause to request an SDCCH. 
After assignment of the SDCCH, the LMU returns an RR Paging Response. 

4) Because the BSC serving the LMU is associated with a SMLC and the Channel Request message in step 3 
contained an LMU establishment cause, the BSC transfers the Paging Response to the SMLC, rather than MSC, 
in a BSSAP Complete Layer 3 Information message contained in an SCCP Connection Request. 

5) The SMLC performs normal authentication and ciphering if this is needed for the LMU. The SMLC shall not 
assign a TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS by a VLR. 
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6) If the SMLC needs to send data to the LMU, it may send one or more DTAP-LE REGISTER, FACILITY or 
RELEASE COMPLETE messages to the BSC. Each DTAP-LE message contains an embedded LLP message 
and an indication of whether release of the SDCCH by the LMU is forbidden. Each DTAP-LE message is 
transferred by the BSC to the LMU. 

7) The SMLC may initiate release of the SDCCH to the LMU by sending a ESS AP Clear Command to the BSC. 

8) The BSC returns a BSSAP Clear Complete. 

9) The BSC orders release of the SDCCH by sending an RR Channel Release to the LMU. 

10)The SMLC releases the SCCP connection to the BSC by sending an SCCP Released message. 

1 1) When the LMU has LCS data to send and does not currently have a signaling link, it sends an RR Channel 
Request to the serving BTS to request an SDCCH. The RR Channel Request contains an establishment cause 
identifying an LMU. After assignment of the SDCCH, the LMU sends a DTAP CM Service request to the 
serving BSC. 

12)Because the BSC serving the LMU is associated with a SMLC and the Channel Request message contained an 
LMU establishment cause, the BSC forwards the CM Service Request with an indication that this came from an 
LMU to the SMLC, rather than MSC, inside a BSSAP Complete Layer 3 Information message that is contained 
in an SCCP Connection Request. 

13) The SMLC performs authentication and ciphering if needed for the LMU. Otherwise, a CM Service Accept is 
returned. The SMLC shall not assign a TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS 
by a VLR. 

14) The LMU sends one or more DTAP-LE REGISTER, FACILITY or RELEASE COMPLETE messages to the 
serving BSC each containing an embedded LLP message. The BSC forwards each DTAP-LE message to the 
SMLC. 
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8.3.3.2 Information Transfer using a TCH 



SMLC 



BSC 



1 . Setup Signaling Cor lection using an SDCCH 
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3. DTAP Ca Confirmed 



4. Assignment Request 
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Figure 21 : Information Transfer between a SMLC and a Type A LMU using a TCH 

1) The SMLC establishes a signaUng connection to the LMU using an SDCCH. 

2) The SMLC sends a DTAP Setup to the LMU with the requested bearer capability. 

3) The LMU returns a DTAP Call Confirmed. 

4) The SMLC initiates traffic channel assignment by sending a BSSAP Assignment Request to the BSC. 

5) The BSC requests channel activation in the BTS and then sends an RR Assignment Command to the LMU. 

6) The LMU acknowledges TCH assignment. 

7) The BSC confirms TCH assignment. 

8) The LMU confirms call establishment. 

9) The SMLC acknowledges the LMU confirm. 

10) DTAP-LE Connection Oriented Information messages are transferred between the SMLC and LMU on the 
established TCH: these are transparent to the BSC. 

1 l)The SMLC initiates release of the TCH by sending a DTAP Disconnect to the LMU 

12) The LMU returns a DTAP Release. 

13) The SMLC sends a DTAP Release Complete. 

14) The SMLC initiates release of the TCH by sending a BSSAP Clear Command to the BSC. 
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15)The BSC returns a BSSAP Clear Complete. 

16) The BSC orders release of the TCH by sending an RR Channel Release to the LMU. 

17) The SMLC releases the SCCP connection to the BSC by sending an SCCP Released message. 

8.3.4 LCS Information Transfer between a SMLC and a Type B LMU 

A SMLC uses the procedure shown below in order to exchange LCS information with a TypeB LMU. 



SMLC 



BSC 



1.SCCP UDT [BSSAP-LE 
Connectionless Information] 



BTS or LMU 



2. Location Information 



3. Location Information 



4. SCCP UDT [BSSAP-LE 
Connectionless Information] 

Figure 22: Information Transfer between a SIVILC and a Type B LMU 

1) The SMLC passes a BSSAP-LE Connectionless Information message to the BSC containing an embedded LLP 
message and the LAC/CI cell address identifying the LMU. The BSSAP-LE message is transferred inside an 
SCCP Unitdata message. 

2) The BSC transfers the embedded LLP message to either the BTS associated with the LMU or the LMU itself 
inside a Location Information message. The BTS or LMU is identified using the LAC/CI received in step L 

3) When the LMU has positioning information to return to the SMLC, either it or its associated BTS transfers this 
to the BSC inside a Location Information message.. 

4) The serving BSC forwards the LLP message to the SMLC inside a BSSAP-LE Connectionless Information 
message contained in an SCCP Unitdata message. The BSSAP-LE message contains the LAC/CI address 
identifying the LMU. 



8.4 



Common Control Procedures for LMUs 



These procedures are applicable to any Type A LMU and may be used for any Type B LMU to enable control of the 
LMU by its associated SMLC. The procedures assume support for the establishment of a signaling link and the transfer 
of LLP messages between an SMLC and LMU that are defined in the common procedures to support access to an LMU, 
section 8.3. Consequently, details of signaling link establishment and message transfer by a BSC and BTS are not 
shown. 



£75/ 



3GPP TS 43.059 version 4.2.0 Release 4 



34 



ETSI TS 143 059 V4.2.0 (2001-08) 



8.4.1 Reset Procedure 

The reset procedure enables an SMLC to return an LMU to a known initial state in which no measurement or O&M 
operations are outstanding or being performed. 



SMLC 



BSC 



1. LLP Reset Invoke 



2. LLP Reset Rsturn Result 



LMU 



message 



Figure 23: Reset Procedure for a Circuit IVIode LIVIU 

1) After first establishing a signaling connection to the LMU (see section 8.3), the SMLC sends an LLP Reset 
Invoke to the LMU via BSC. 

2) The LMU cancels any LCS measurement and O&M tasks previously ordered by the SMLC. The LMU then 
returns an LLP Reset Return Result to the SMLC. 



8.4.2 



Status Query Procedure 



The Status Query procedure enables an SMLC to verify the status of an associated LMU. The procedure may be 
instigated periodically or following any loss of communication with the LMU. 



SMLC 



BSC 



1 . LLP Status Query 



LMU 



Invoke message 



2. LLP Status Quey Return Result 



Figure 24: Status Query Procedure for a Circuit IVIode LMU 

1) After first establishing a signaling connection to the LMU (see section 8.3), the SMLC sends an LLP Status 
Query Invoke to the LMU via BSC. 

2) The LMU returns an LLP Status Query return result, indicating the number of active measurement jobs for each 
type of measurement (e.g. RIT) and the number of active O&M jobs in the LMU that were previously ordered by 
the SMLC. 



8.4.3 



Status Update Procedure 



The Status Update procedure enables an LMU to report status information to its associated SMLC. The procedure may 
be instigated for the following reasons: 

1 . Periodically 

2. Power-on condition or recovery from failure with loss of memory 

3. Impending availability or unavailability for O&M reasons 

4. Location Update by a Type A LMU in a new Location Area. 
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SMLC 



BSC 



2. LLP Status Updcte Return Result 



LMU 



1 . LLP Status Upd ate Invoke message 



Figure 25: Status Update Procedure for a Circuit IVIode LIVIU 

1) After first establishing a signaling connection to the SMLC (see section 8.3), the LMU sends an LLP Status 
Update Invoke to the SMLC via BSC. This message shall include the reason for the Status Update, the number 
of active and outstanding jobs of each category in the LMU and the current hardware status. 

2) The SMLC returns an LLP Status Update return result to acknowledge receipt of the Status Update. 

8.5 Exception Procedures 

The procedures in this section apply to all location procedures where a BSSAP-LE Perform Location Request has been 
sent to an SMLC by a BSC requesting some location service (e.g. provision of a location estimate for a target MS or 
transfer of assistance data to a target MS). 

8.5.1 Procedures in tine SIVILC 

When a request for a location estimate fails due to failure of a position method itself (e.g. due to inaccurate or 
insufficient position measurements and related data) and the SMLC is unable to instigate another positioning attempt 
(e.g. due to a requirement on response time), the SMLC may return a BSSAP-LE Perform Location response containing 
a less accurate location estimate (e.g. based on serving cell and timing advance). If a less accurate estimate is not 
available or will not meet the accuracy requirement, the SMLC shall instead return a BSSAP-LE Perform Location 
response message containing no location estimate and indicating the cause of failure. 

When a request for any other location service (e.g. transfer of assistance data to a target MS) fails for any reason and the 
SMLC is unable to reattempt the service, the SMLC shall return a BSSAP-LE Perform Location response message 
indicating the cause of failure. 

When a location service request is interrupted by some other unrecoverable error event inside the SMLC, the SMLC 
shall immediately terminate the location service attempt and return a BSSAP Perform Location Response message 
containing the reason for the location service cancellation. In that case, any dialogue previously opened with an LMU or 
BSC for the purpose of instigating position measurements for any MS being located may also be aborted by the SMLC. 

If the SMLC receives a BSSAP-LE Perform Location Abort indication for a previous location service request from the 
BSC, it shall immediately terminate the location service attempt and may abort any dialogues used for the location 
service attempt that may still exist with any LMUs. The circumstances of the abort may still ensure cancellation of any 
such procedure (see section on BSC). 

If the SMLC has instigated any location releated procedure in the Target MS or its serving BSC and receives a BSSLAP 
Reject, BSSLAP Abort or BSSLAP Reset indication from the BSC, it shall cancel the location service attempt and may 
abort any dialogues for this that currently exist with any LMUs. For a BSSLAP Abort, the SMLC shall then either 
return any location estimate already derived, if this was requested and is sufficient for the requested QoS, or return a 
BSSAP-LE Perform Location response indicating failure of the location service and the cause of the failure in the 
BSSLAP Abort. For a BSSLAP Reject and BSSLAP Reset, the SMLC has the additional option of restarting the 
location service attempt and using the same or a different position method where a location estimate was requested. A 
decision to restart the location service shall take into account the cause of the location service failure as conveyed in the 
BSSLAP Reject or BSSLAP Reset and whether, in the case of successful intra-BSC handover, the new cell for the 
target MS is still associated with the SMLC. If the SMLC receives a BSSLAP Reject or BSSLAP Reset with a cause 
indicating intra-BSC handover and with a new cell identity for the target MS that is not associated with the SMLC, the 
SMLC shall return a BSSAP-LE Perform Location response containing either a location estimate, if requested, available 
and sufficient for the requested QoS, or a failure cause indicating "intra-BSC" handover. 
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8.5.2 Procedures in an LMU 

An LMU shall return an error indication to its controlling SMLC when location measurements previously ordered by 
the SMLC cannot be provided due to any error condition. 

8.5.3 Procedures in tine BSC 

8.5.3.1 General Procedures 

The BSC serving a target MS shall supervise any network or MS location service procedure, including transfer of 
positioning assistance data to an MS, and shall only allow one such procedure to be active at any time. If a new 
procedure is instigated by the SMLC for any target MS, the BSC shall cancel any previous procedure without notifying 
the SMLC or target MS. The new procedure shall then be treated according to the prevailing conditions. If a location 
information transfer to an MS initiated by an SMLC is not active, the BSC shall discard any RRLP message or message 
segment received from the MS. This precludes the initiation of any location service procedure from an MS. 

Depending on the location procedure and its current state of execution, a serving BSC may chose to defer certain radio 
related events (e.g. handover) to avoid interference with location - refer to the later sections for each position method. 
A serving BSC shall abort all existing location related procedures for a particular target MS without notifying a target 
MS if the DCCH to the target MS or the SCCP connection to the SMLC is released. In the event of an abort with a 
SMLC, the BSC shall attempt to notify the SMLC using a BSSAP-LE Perform Location Abort. 

8.5.3.2 Rejection of an SMLC Positioning Request 

The BSC may reject any request from an SMLC for positioning or transfer of assistance data for a target MS if the 
request cannot be performed for reasons other than interaction with handover or other RR management. If the request is 
rejected, the BSC shall return a BSSLAP Reject to the SMLC containing the cause of rejection. 

8.5.3.3 Interaction with Inter-BSC Handover 

The BSC shall reject any request from an SMLC for positioning or transfer of assistance data while an inter-BSC 
handover procedure is ongoing and shall return a BSSLAP Abort to the SMLC. 

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already in 
progress if inter-BSC handover is needed and is not precluded by the particular location procedure and its current state. 
When a location procedure is terminated and there is an active BSSLAP transaction, the BSC shall return a BSSLAP 
Abort message to the SMLC after the BSSAP Handover Required has been sent to the serving MSC. The BSSLAP 
Abort shall contain the cause of the location procedure failure. When a location procedure is terminated and there is no 
active BSSLAP transaction, the BSC shall send a BSSAP-LE Perform Location Abort message to the SMLC after the 
BSSMAP Handover Required has been sent to the serving MSC. 

8.5.3.4 Interaction with Intra-BSC Handover and other RR Management Procedures 

The BSC shall reject any request from an SMLC for positioning or transfer of assistance data while an intra-BSC 
handover or other intra-BSC RR management procedure involving the target MS is ongoing and shall return a BSSLAP 
Reset to the SMLC when the handover or other RR management procedure is complete or has timed out in the BSC. 

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already in 
progress if an intra-BSC handover or other intra-BSC RR management procedure is needed and is not precluded by the 
particular location procedure and its current state. When location procedure is terminated, the BSC shall return a 
BSSLAP Reset message to the SMLC after the intra-BSC handover or other RR management procedure is complete or 
has timed out in the BSC. The BSSLAP Reset shall contain a cause indication, the current serving cell identity and may 
contain measurement information for the target MS (e.g. TA value). 
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8.5.3.5 Priority of Handover and Other RR Management Procedures 

If the transfer of RRLP messages between an SMLC and target MS is interrupted by intra-BSC handover, inter-BSC 
handover or any other intra-BSC RR management procedure, the BSC shall avoid delay to the handover or RR 
management procedure by employing the preemption capability defined in 3GPP TS 44.006 and 3GPP TS 24.008. This 
allows an RR Handover Command or other RR management command sent to the target MS to be assigned a "high" 
priority at the data link level enabling preemption of "low" priority RR Application Information messages (carrying 
RRLP messages) which may have been sent earlier. This procedure ensures that any RRLP data still untransmitted to 
the MS will be preempted (and discarded) by the data link layer in the BTS prior to transmission of the Handover 
Command or other RR Management command. 

8.5.3.6 Interaction with Segmentation 

When requested to transfer a segmented RRLP message between an SMLC and target MS, the BSC shall discard all 
received RRLP segments if the transfer procedure in the BSC cannot be supported or is aborted. The BSC need not wait 
until all RRLP segments are received before notifying the SMLC of the failure of the RRLP procedure with a BSSLAP 
Abort, Reject or Reset message. 

If a location service procedure for a target MS is not currently underway or previously failed, the BSC shall discard all 
BSSLAP segments received from an SMLC for this MS until it receives the first or only segment of a new BSSLAP 
message. Once a location service procedure has been started involving RRLP message transfer to a target MS, the BSC 
shall discard all RRLP segments received from the MS until it receives the first or only segment of a new RRLP 
message. The new RRLP message shall then be treated according to the state of the RRLP message transfer as 
described in section 8.L 

Further details regarding transfer and segmentation of RRLP messages between a BSC and MS can be found in 3GPP 
TS 24.008. 

8.5.3.7 Overload 

The BSC may indicate an inability to support location due to overload by rejecting with a cause indicating congestion a 
BSSAP Perform Location request received from the MSC. If a SMLC has rejected a request from the BSC to perform 
location with a cause indicating congestion, the BSC shall convey the rejection and cause to the MSC if the request was 
MSC initiated. If the request was initiated by the BSC, the BSC may reduce the frequency of its location requests to the 
SMLC according to the rules in 3GPP TS 49.031, which give precedence to location service requests with a higher 
priority. 



8.6 Procedures in the Target MS 



A target MS shall terminate any positioning procedure or the transfer of RRLP positioning assistance data without 
sending any response to the SMLC if any RR message is received from the BSC that starts some other RR management 
procedure, including a new positioning procedure. The new RR procedure shall then be executed by the MS. 

8.7 Further Procedures for Handover 

Handover procedures are described in 3GPP TS 23.2710. 
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Positioning procedures 



The following section describes the positioning procedures for Timing Advance, Enhanced Observed Time Difference 
and Global Positioning System. 



9.1 Positioning Procedure Initiation 



9.1 .1 Core Network Position Procedure Initiation over the A interface 

This procedure is used by the Core Network to start the positioning procedure in GERAN over the A interface. 



MSC 



1. BSSAP Perform Location 
Request 



BSC SMLC 



MS 



2. Common Positioning Procedure 
forCS domain 



3. BSSAP Perform Location 
Response 



Figure 26: Positioning Procedure Initiation Over A Interface 

1) The MSC sends the BSSAP Perform Location Request message on the existing SCCP connection for the target 
MS to request the BSC to start the positioning procedure. The Location Type is always included. Depending on 
the type of location request, additional parameters may be included to provide the Cell Identifier, Classmark 
Information Type 3, LCS Client Type, Chosen Channel, LCS Priority, Quality of service, GPS Assistance Data, 
and APDU.2.) 

2) The common positioning procedures for CS domain are executed (see below). 

3) The BSC sends the BSSAP Perform Location Response message to the MSC. A location estimate, positioning 
data, deciphering keys, or LCS Cause may be included. 
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9.1 .2 Positioning Procedure Initiation from an Internal LCS Client 

The figure below illustrates how a serving BSC may obtain the location of a target MS that is already in dedicated mode 
on behalf of some PLMN operator LCS client in GERAN - e.g. to support handover. The procedure is valid when local 
regulatory requirements do not require privacy checking for PLMN operator initiated location. 
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Figure 27: Positioning Procedure Initiation from an Internal LCS Client 

1) An LCS client within the GERAN requests the current location of a target MS from the serving BSC 

2) The common positioning procedures for CS domain are executed see Figure 28 below. The BSC returns the MS 
location estimate to the requesting LCS client. 

9.2 Common Positioning Procedure for CS Domain 

This procedure is common to all positioning methods in the CS domain. 



SMLC 



BSC 
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3. BSSAP-LE Perform Location 
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Figure 28: Common Positioning Procedure for CS Domain 

1) The BSC sends the BSSAP-LE Perform Location Request message to request the SMLC to start the positioning 
procedure. 
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2) If location information is requested and the location accuracy within the QoS, if provided, can be satisfied by the 
reported cell ID and, if available, TA value, the SMLC may send a BSSAP-LE Perform Location Response 
message immediately. Otherwise, the SMLC determines the positioning method and instigates the particular 
message sequence for this method defined in subsequent sections. If the position method returns position 
measurements, the SMLC uses them to compute a location estimate. If there has been a failure to obtain position 
measurements, the SMLC may use the current cell ID and, if available, TA value to derive an approximate 
location estimate. If a computed location estimate is returned for an MS based position method, the SMLC may 
verify consistency with the current cell ID and, if available, TA value. If the location estimate so obtained does 
not satisfy the requested accuracy or the location attempt failed, e.g. due to missing data, and sufficient response 
time still remains, the SMLC may instigate a further location attempt using the same (e.g. providing more 
assistance data to MS) or a different position method. If a vertical location co-ordinate is requested but the 
SMLC can only obtain horizontal co-ordinates, these may be returned. Requirements on the geographic shape 
encoded within the 'position information' parameter may exist for certain LCS client types. The SMLC shall 
comply with any shape requirements defined in 3GPP. The SMLC in a certain country should attempt to comply 
with the shape requirements defined for a specific LCS client type in the relevant national standards of that 
country. 

3) If location assistance data is requested, the SMLC transfers this data to the MS as described in subsequent 
sections. The SMLC determines the exact location assistance data to transfer according to the type of data 
specified by the MS, the MS location capabilities and the current cell ID. If deciphering keys are requested the 
SMLC obtains the current keys. 

4) The SMLC sends the BSSAP-LE Perform Location Response message to the BSC containing any location 
estimate or deciphering keys. In case of failure the cause value may be included. 

9.3 TA Based Positioning in CS Domain 

The TA is based on the existing Timing Advance (TA) parameter. The TA value is known for the serving BTS. To 
obtain TA values in case the MS is in idle mode a special call, not noticed by the GSM subscriber (no ringing tone), is 
set up. The cell-ID of the serving cell and the TA is returned as the result of the TA. 

9.3.1 Definition of TA states 

9.3.1.1 MS in IDLE state 

In IDLE state the MS may be paged or may request an originating (e.g. emergency) call. The paging response message 
or CM Service Request, in each case respectively, received in COMPLETE_LAYER_3 message may contain location 
information that includes the TA value. If available, the TA value and other location information shall be provided to 
the SMLC by the requesting BSC along with the current serving cell ID in the BSSAP-LE Perform Location request. 
This enables TA based positioning in the SMLC without any further interactions. 

9.3.1 .2 MS in DEDICATED State 

In DEDICATED state the SMLC shall send a TA_REQUEST to request the TA value from the serving BSC. The BSC 
shall respond with a TA_RESPONSE carrying the TA value and possibly other radio measurements from the MS. The 
associated procedure is described in the next section. 
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9.3.2 TA Positioning Procedure 



This TA positioning procedure is generic for a standalone SMLC or integrate SMLC in the BSC. 



SMLC 



BSC 



1 . BSSAP-LE Connection Oriented 

Information 

(TA Request) 



MS 



2. BSSAP-LE Connection Oriented 
Information 
(TA Response) 

Figure 29: TA Positioning Procedure for the SIVILC 

1) The SMLC sends a BSSAP-LE Connection Oriented Information message to the BSC serving a particular target 
MS. The APDU parameter in this message contains a BSSLAP TA Request. 

2) The BSC returns the current TA value and current serving cell for the target MS to the SMLC in a BSSLAP TA 
response contained within a BSSAP-LE Connection Oriented Information message. The TA response may also 
include the latest measurement results received from the target MS for the serving and neighbouring cells. The 
SMLC then derives a location estimate for the target MS based on the received serving cell ID, TA value and 
other measurement results if included. 

9.3.3 Unsuccessful TA positioning procedure in BSC 

There are three messages defined to handle error scenarios during positioning procedure in BSC. 
The messages are 1) Reject, 2) Abort and 3) Reset. Refer to 3GPPTS 48.0710 for details. 

After receiving the BSSLAP TA Request in BSC, a Reject will be sent with proper cause value from BSC to SMLC in 
"BSSAP-LE Connection Oriented Information Message" if TA positioning cannot be performed in BSC at that time for 
reasons other than handover or another ongoing RR management procedure. 

An Abort or Reset is possible if the TA positioning cannot be done in BSC during that time. Reset is sent to SMLC to 
indicate when the positioning needs to be restarted after temporary interruption due to intra BSC HO or other intra-BSC 
RR management. Abort is used to indicate to SMLC the failure of the current TA positioning attempt (e.g. due to inter- 
BSC handover) and allowing a new one from application level. 

9.4 E-OTD and GPS Positioning Procedures 
9.4.1 General procedures 

For any location request where the highest priority level is assigned and MS-based GPS positioning is not used, the 
SMLC functionality shall provide sufficient assistance data to a target MS to enable a location estimate or location 
measurements to succeed according to the required QoS on the first attempt. The SMLC shall not assume in this case 
that the target MS already possesses assistance data. For a lower priority location request or when MS-based GPS 
positioning is used, the SMLC may reduce the assistance data provided to a target MS on the first location attempt. 



9.4.2 Positioning Request 



This signaling flow is generic for all MS based or assisted location methods (MS Based E-OTD, MS Assisted E-OTD, 
MS Based GPS, and MS Assisted GPS) The signaling flow below applies to integrated and standalone SMLCs in a 
circuit switched network. 

If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation, see section 6.1.2, and transfer the LCS 
assistance data more reliably, this procedure may be preceded by an "Assistance Data Delivery" procedure. Note, that 
part of the entire set of assistance data may be included in the RRLP Measure Position Request even when the message 
is preceded by an "Assistance Data Delivery" procedure. 
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2. RRLP Measure Position ReqLiest 



MS 
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4. RRLP Measure Position Response 



5. RRLP Measure Position Response 



Figure 30: E-OTD or GPS Position Request Flow 

1) The SMLC may precede the RRLP MEASURE POSITION REQUEST with an optional Assistance Data 
Delivery procedure. 

2) The SMLC determines possible assistance data and sends RRLP MEASURE POSITION REQUEST to the BSC. 

3) The BSC forwards the positioning request including the QoS and any assistance data to the MS in a RRLP 
MEASURE POSITION REQUEST. 

4) The MS performs the requested E-OTD or GPS measurements, if needed assistance data is available in the MS. 
If the MS is able to calculate its own location and this is required and needed assistance data is available in MS, 
the MS computes a location estimate based on E-OTD or GPS measurements. In case of E-OTD, any data 
necessary to perform these operations will either be provided in the RRLP MEASURE POSITION request or 
available from broadcast sources. In case of Assisted GPS (both MS based GPS and MS assisted GPS) and first 
positioning attempt. Acquisition Assistance data and optionally Differential GPS data will be provided in the 
RRLP MEASURE POSITION REQUEST. In case of MS based GPS and further positioning attempt (failure in 
first attempt due to missing assistance data), complete GPS assistance data excluding Acquisition Assistance 
data will be provided in the RRLP MEASURE POSITION REQUEST and possibly preceding RRLP 
ASSISTANCE DATA messages. The resulting E-OTD or GPS measurements or E-OTD or GPS location 
estimate are returned to the BSC in a RRLP MEASURE POSITION RESPONSE. If the MS was unable to 
perform the necessary measurements, or compute a location, a failure indication identifying the reason for failure 
(e.g. missing assistance data) is returned instead. 

5) BSC forwards the RRLP MEASURE POSITION response to SMLC. 



9.4.3 Assistance Data Delivery 



This signalling flow is generic for all MS based location methods (MS Based and Assisted E-OTD, and MS Based or 
MS Assisted GPS) in a circuit switched network. 

If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation and transfer the LCS assistance data more 
reliably, the sequence 1 -4 illustrated in the figure below may be repeated several times to deliver more assistance data 
than can be sent by one RRLP Assistance Data Delivery message. In this case, each individual message is independent 
such that the data received in one message is stored in the MS independently of the other RRLP Assistance Data 
messages (i.e. an error of delivery of one message does not require a retransmission of all the RRLP Assistance Data 
messages). The SMLC shall indicate in the RRLP ASSISTANCE DATA message if more RRLP ASSISTANCE DATA 
messages will be used after the current one in order to deliver the entire set of assistance data. Data that is specific to the 
current cell should be sent in the last message this is recommended so that assistance data for the correct cell is 
available to the MS after a handover. 
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Figure 31 : E-OTD or GPS Assistance Data Delivery Flow 

1) The SMLC determines assistance data and sends it in the RRLP ASSISTANCE DATA message to the BSC. 

2) The BSC forwards the assistance data to the MS in a RRLP ASSISTANCE DATA message. 

3) The MS acknowledges the reception of complete assistance data to the BSC with a RRLP ASSISTANCE DATA 
Ack. 

4) The BSC forwards the RRLP ASSISTANCE DATA Ack message to the SMLC. 

9.4.4 Error Handling for E-OTD and GPS in CS Domain 

This section describes error handling for positioning and transfer of assistance data for E-OTD and GPS. For a 
description of error handling involving segmentation, refer to section 8.5 Exception Procedures. 

Case 1 : When the RRLP request comes to BSC for E-OTD and GPS, The BSC will send a BSSLAP reject 

message to SMLC if the request cannot be supported in the BSC for reasons other than an ongoing intra 
BSC or inter BSC handover or other ongoing RR management procedure. For an ongoing intra BSC HO 
or other RR management procedure, the BSC shall return a BSSLAP Reset when the handover or RR 
management procedure is complete. The SMLC may then start the RRLP request (if there is time) again. 
For ongoing inter-BSC HO, the SMLC shall return a BSSLAP Abort. The location service request may 
then restart from the LCS Client, VMSC or SGSN. 

Case 2: When the RRLP request comes to BSC from SMLC, BSC sends the "RRLP request" to the MS if there is 
no ongoing HO or other RR management procedure at that point. If an intra-BSC HO or other RR 
management procedure is initiated in BSC, the BSC sends the HO or other RR management command to 
MS. A timer will then be started in BSC, the duration of which is network dependent, but typically 6 (six) 
seconds. Upon receiving the HO of other RR management command, the MS will stop the location 
procedure and start on handover or other RR management procedure, since this has higher priority than 
location. The MS will then send the HO complete or other RR management response message to BSC. 
When this message is received before the expiration of BSC timer, a BSSLAP Reset message will be sent 
to SMLC from BSC. The Reset will tell SMLC to start another location service request if there is enough 
time. 

Case 3: During intra-BSC HO or other intra-BSC RR management procedure, if a HO complete or RR 

management procedure completion was not received in BSC and the corresponding timer expired. In this 
case a reset or abort message will be sent to SMLC indicating MS timeout. The location service may then 
restart from either the SMLC if a reset was sent or from the LCS Client, VMSC or SGSN if an abort was 
sent. 

Case 4: If an inter-BSC handover is needed during a location procedure or if the BSC times out on an RRLP 
response from the target MS, the BSC shall send a BSSLAP Abort to the SMLC. The location service 
attempt may then be restarted from the LCS Client, VMSC, or SGSN. 
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9.4.5 Error Handling for the SMLC 
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Figure 32: Error Handling for the SMLC 

9.4.6 Broadcast of Assistance Data 

In MS Based E-OTD, MS Based GPS and MS Assisted GPS systems, there may be a need for assistance data to be 
broadcast to the MS. The assistance data to be broadcast for MS Based E-OTD contains the Real Time Difference 
(RTD) values (in case of a non-synchronised network) and Base Transceiver Station (BTS) coordinates. In addition, the 
broadcast data contains other information simplifying the E-OTD measurements. The broadcast of GPS assistance data 
makes available reference time, reference location, differential GPS (DGPS) correction data, ephemeris and clock 
correction data, almanac data, UTC offset, ionospheric delay, and satellite health status for GPS-based positioning. It 
improves the location accuracy for MS Based implementations, increases the sensitivity, enables LMU-independent 
GPS time dissemination and assists the acquisition of satellite signal for both MS Based and MS Assisted 
implementations. 

The E-OTD assistance data to be broadcast is in compressed format where the redundant information is not included. 
The MS is capable to reconstruct the E-OTD assistance data using the message header information. The length of the 
message is depending on how many neighbours are included in the E-OTD assistance data as well as whether the 
redundant information can be removed from the message. The typical size of one broadcast message will be less than 82 
octets. Part of the broadcast message (serving and neighbour base station coordinates) may be ciphered. 

The GPS assistance data to be broadcast is under the same common message header with three types of data sets (or 
lEs), which may have different broadcast rates to minimise the bandwidth impact while still maintaining the same 
positioning capabilities. The first type consists of differential GPS (DGPS) correction data. The second type consists of 
ephemeris and clock correction data. The third type consists of almanac and other data. The length of this message is 82 
octets and the data IE part may be ciphered. 

The contents of the broadcast message for the E-OTD and GPS assistance data is described in 3GPP TS 44.035 0. The 
support for these broadcast messages is optional for network and MS. 
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The broadcast channel which is used to broadcast the E-OTD and GPS assistance data make use of the existing basic or 
extended CBCH and SMSCB DRX service. The LCS broadcast messages need to be either scheduled, or prioritised 
over other broadcast messages to avoid any delay. 



9.4.6.1 



Point-To-Multipoint Assistance Data Broadcast Flow 



This signalHng flow is generic for MS Based E-OTD, MS Based GPS and MS Assisted GPS methods. The E-OTD/GPS 
Assistance Data Broadcast Message is created in SMLC and the whole message including the ciphered parts and 
parameters to control the transfer are transferred with below flow from SMLC to MS. SMSCB DRX service is used for 
LCS assistance data broadcast. Prior receiving the first schedule message MS should read first block of each message 
lot to be able to receive the LCS Broadcast Data or the schedule message. After receiving the schedule message MS 
should receive the LCS Broadcast Data messages according the schedule information. 
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Figure 33: E-OTD/GPS Broadcast Data Flow 

1) SMLC sends the complete broadcast message to CBC with LCS Broadcast Data message. This LCS Broadcast 
Data message contains the data to be broadcasted as well as parameters that indicate to which BTS the broadcast 
message is targeted and what time the broadcast should happen. LCS Broadcast Data (data & parameters) 
message may also contain the SMSCB scheduling information which can be utilised for the SMSCB DRX 
feature specified in 3GPP TS 44.012 specification. SMSCB DRX operation is required in order that MS 
performance can be optimised. 

2) CBC starts message transfer to BSC and BTS according to 3GPP TS 23.041 

3) LCS Broadcast Data Response message from CBC to SMLC is used to indicate that the LCS Broadcast Data has 
been delivery request has been fulfilled. This message is not mandatory 

4) BTS starts the message transfer to MS according to 3GPP TS 23.041 0. 
Implementations that have SMLC and/or CBC integrated into BSC may use other message signalling. 



9.4.6.2 



Ciphering 



In order for the operators to control the access to the assistance data, parts of the broadcast data may be ciphered. 
Ciphering is done with a specific key delivered by the network for this purpose. The deciphering keys may be requested 
by the MS as described in 3GPP TS 23.2710. The LCS Broadcast Data, when ciphered, will be partially ciphered 
according to the LCS broadcast message definitions specified in 3GPP TS 44.0350. The parts that will be ciphered in E- 
OTD LCS Broadcast Data message are neighbour RTD values, serving and neighbour BTS coordinates. For GPS, all 
assistance data may be ciphered. The MS is capable to decipher the broadcast message (ciphered parts) using the cipher 
key (56 bits) delivered from the Core Network to MS and using the Ciphering Serial Number (16 bits) included in the 
broadcast message. 
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9.4.6.2.1 



Algorithm 



The algorithm used for ciphering is the standard 56-bit DES algorithm. The deciphering of broadcast messages is done 
in the MS. SMLC ciphers the LCS Broadcast Data message (part of message is ciphered) using the deciphering keys 
(56 bits) and Ciphering Serial Number (16 bits) included in broadcast message using 56-bit DES algorithm. 

The ciphered part is variable length with one bit resolution. From LCS Broadcast Data message header MS can compute 
what part of message is ciphered. 

Inputs to the 56-bit DES algorithm are the following: 

56-bit key K (deciphering key) 

16-bit Ciphering Serial Number from broadcast message which is denoted here by IV (initialisation vector) 

plaintext bits (the ciphered part of broadcast message) 

Encryption is done by producing a mask bit stream which is then added bit-by-bit to the plaintext data (XOR-operation) 
to obtain the ciphertext data. First IV is concatenated with 0-bits in order to achieve a 64-bit block Ii. This block is then 
encrypted by the DES algorithm using the key K. Output is a 64-bit block I2. This constitutes the first 64 bits of the 
mask bit stream. If the message is longer than 64 bits, then more bits are needed. Those are produced by encrypting I2 
again by the DES algorithm using the key K. Output is a 64-bit block I3. This constitutes the next 64 bits of the mask bit 
stream. This iteration is continued until enough bits are produced. The unnecessary bits from the last 64-bit block Ij are 
discarded. Below Figure 34 describes the first two mask bit generations and the two ciphered 64-bit blocks. 




2nd 64-bit ciphered bloci< to the broadcast message 



Figure 34 : Ciphering Algorithm 

Decryption is done similarly. The same mask bit stream is produced. This time the mask stream bits are added bit-by-bit 
(XORed) to the ciphertext data bits. The result will be the plain text data. 
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9.4.6.3 Deciphering key control and delivery to MS 

The deciphering keys are needed in MS if the LCS Broadcast Data (ciphered parts) is ciphered. The deciphering keys' 
control system contains two keys (the Current Deciphering Key and the Next Deciphering Key) and the Ciphering Key 
Flag (indicating the current Ciphering Key Flag state in the location area in the time that the deciphering key set is 
delivered from SMLC to MS). Two Deciphering Keys are needed in order to overcome the problem of unsynchronised 
nature of the periodic location updates that MSs make in the location area. The SMLC controls the keys and there are 
following requirements related to the deciphering keys: 

Deciphering Key Set (Current and Next Deciphering Key, Ciphering Key Flag) are always location area specific. 

One SMLC controls the deciphering key set changes inside the location area and in case several SMLCs in the 
location area then one coordinating SMLC for the deciphering key set control must be nominated. The SMLC 
configuration is done with O&M procedures. 

The coordinating SMLC delivers the new deciphering key set to the other SMLCs with SMLCPP protocol when 
the deciphering key set changes. The Ciphering Key Flag in the LCS Broadcast Data message is changed only 
when the coordinating SMLC changes the deciphering key set and delivers the new set to other SMLCs in the 
same location area. 

The SMLCs upon receiving the new deciphering key set, start using immediately the new set in the LCS 
Broadcast Data message. The coordinating SMLC also starts using the new set same time. 

The deciphering key set changes always following way when the new set is generated: 

The Next Deciphering Key comes to the Current Deciphering Key in the new set 

One new key is taken into use and named as the Next Deciphering Key 

The Ciphering Key Flag changes the state 
. The Ciphering Key Flag controls the MS key usage (Current/Next Deciphering Key) as follows: 

After receiving the new deciphering key set, MS starts using the new set immediately. 

The Ciphering Key Flag in the LCS Broadcast Data message and the one received returned to the MS should 
have same polarity. This means that MS starts using the Current Deciphering Key immediately. 

When the Ciphering Key Flag state changes in the LCS Broadcast Data message then MS starts to use the Next 
Deciphering Key for deciphering the broadcast message. The Next Deciphering Key becomes now the Current 
Deciphering Key in MS. 
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The following Figure 35 describes the deciphering key delivery mechanism. 
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Figure 35: Deciphering key delivery 

First the key A is the Current Deciphering Key and key B is the Next Deciphering Key 

When the SMLC changes to use the key B (Next Deciphering Key) then the Deciphering Key Flag state is 
changed in the LCS Broadcast Data message. At this point the coordinating SMLC delivers the new deciphering 
key set to other SMLCs in the same location area as well as to MS when MS is requesting the keys during the 
location update (IMSI Attach, Normal or Periodic Location Update) 

The new deciphering key set contains now key B as the Current Deciphering Key, key C as new Next 
Deciphering Key and the Ciphering Key Flag currently in use in that location area. 

When the SMLC changes to use the key C (Next Deciphering Key) then the Ciphering Key Flag state is changed 
in the LCS Broadcast Data message. At this point the coordinating SMLC delivers the new deciphering key set 
to other SMLCs in same location area as well as to MS when MS is requesting the new set during the location 
update (IMSI Attach, Normal or Periodic Location Update) 

The new deciphering key set contains now key C as the Current Deciphering Key, key D as new Next 
Deciphering Key and the Ciphering Key Flag currently in use in that location area 

The process continues as above when the keys are changed. The lifetime of one key (Current/Next Ciphering Key) is 
minimum one periodic location update period used in the location area. 
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1 Information storage 



This section describes information storage structures that are mandatory (M), conditional (C) or optional (O) for LCS in 
GERAN, and the recovery and restoration procedures needed to maintain service if inconsistencies in databases occur 
and for lost or invalid database information. 

10.1 SMLC 

Common Data 

The following table holds permanent BTS data: 

Table 2: Permanent SMLC Data for a BTS 



Permanent BTS Data Item 


Status 


Description 


BTS position 


M 


BTS position (latitude/longitude) of the Serving BTS 


CGI 


M 


Cell global identity. 


BSIC 


M 


Base station identity code. 


BCCH 


M 


Frequency of the broadcast carrier. 



The SMLC holds data for its associated LMUs. The main key to LMU data in the SMLC is the IMSI for a Type A LMU 
and a cell site identifier for a Type B LMU. LMU data provides the location capabilities of the LMU (e.g. which 
location and assistance measurements are supported). The following permanent data shall be administered for any 
LMU: 

Table 3: Permanent SMLC Data for an LMU 



Permanent LMU Data Item 


Status 


Description 


Type of LMU 


M 


Indicates if LMU is Type A or Type B 


IMSI 


C 


Main key to data for a Type A LMU. Not applicable to a Type B LMU 


LAC + CI 


C 


Cell site identifier to address a Type B LMU. Not applicable to a Type A 
LMU. 


Signaling Access 


M 


information regarding signalling access to the LMU including the 
following: 

- address of default serving BSC 

- SS7 linl< set to serving BSC (or to an intermediate STP) 


Serving Cell 


M 


identity of the cell in which the LMU is physically located 


Geographic location 


C 


Latitude/longitude coordinates 

Storage of coordinates is mandatory for E-OTD if an LMU is not co- 
located with a BTS 


Position measurement 
functions 





List of supported position measurements 

For each type of position measurement, a list of associated capabilities - 

details are outside the scope of this specification 


Assistance measurement 
functions 





List of supported assistance measurements 

For each type of assistance measurement, a list of associated capabilities 

- details are outside the scope of this specification 


Diagnostic functions 





List of supported diagnostic functions - details are outside the scope of 
this specification 



The SMLC also holds the following temporary data for each LMU for which there has been any previous signalling 
interaction. 
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Table 4: Temporary SMLC Data for an LMU 



Temporary LMU Data Item 


Status 


Description 


Position IVIeasurements 





Ongoing and scheduled position measurements ordered in the 
LIVIU by the SIVILC - details are outside the scope of this 
specification 


Assistance Measurements 


o 


Ongoing and scheduled assistance measurements ordered by 
the SMLC - details are outside the scope of this specification 


O&M Activities 


o 


Ongoing and scheduled O&M activities ordered in the LMU by 
the SMLC - details are outside the scope of this specification 



An LMU contains no mandatory data regarding its associated SMLC. An LMU shall contain permanent data regarding 
its measurement and O&M capabilities and may contain pre-administered data regarding location assistance 
measurements and O&M activities that the LMU is to perform without the need for any command from the SMLC. The 
content of such location measurement and O&M related data is outside the scope of this specification. 

10.2 Recovery and Restoration Procedures 

The LCS recovery and restoration procedures allow temporary data to be recovered or re-initialized following loss or 
corruption of data, such that normal LCS service is rapidly restored and inconsistency between the data held by 
different LCS network elements is removed. For a full description, refer to 3GPP TS 23.007 0. 
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Annex A (informative): 
Change history 
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